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Abstract 



1. Motivation 



The C Object System (Cos) is a small C library which im- 
plements high-level concepts available in Clos, Objective- 
C and other object-oriented programming languages: uni- 
form object model (class, metaclass and property-metaclass), 
generic functions, multi-methods, delegation, properties, ex- 
ceptions, contracts and closures. COS relies on the program- 
mable capabilities of the C programming language to extend 
its syntax and to implement the aforementioned concepts 
first-class objects. Cos aims at satisfying several general 
principles like simplicity, extensibility, reusability, efficiency 
and portability which are rarely met in a single program- 
ming language. Its design is tuned to provide efficient and 
portable implementation of message multi-dispatch and mes- 
sage multi-forwarding which are the heart of code extensi- 
bility and reusability. With COS features in hand, software 
should become as flexible and extensible as with scripting 
languages and as efficient and portable as expected with C 
programming. Likewise, Cos concepts should significantly 
simplify adaptive and aspect-oriented programming as well 
as distributed and service-oriented computing. 

Categories and Subject Descriptors D.3.3 [C Program- 
ming Language} : Language Constructs and Features; D. 1 .5 
[Programming Techniques]: Object-oriented Programming. 

General Terms Object-oriented programming. 

Keywords Adaptive object model. Aspects, Class cluster. 
Closure, Contract, Delegation, Design pattern. Exception, 
Generic function. Introspection, High-order message. Mes- 
sage forwarding, Meta class, Meta-object protocol. Multi- 
method, Open class model. Predicate dispatch. Program- 
ming language design. Properties, Uniform object model. 



* cos project: http : //sourceforge .net/projects/cos 



The C Object System (Cos) is a small framework which 
adds an object-oriented layer to the C programming lan- 
guage C] |2] |3] using its programmable capabilitie^ while 
following the simplicity of Objective-C E |6| and the 
extensibihty of Clos EllillTOl. COS aims to fulfiU sev- 
eral general principles rarely met in a single programming 
language: simplicity, extensibility, reusability, efficiency and 
portability. 

1.1 Context 

Cos has been developed in the hope to solve fundamen- 
tal programming problems encountered in scientific comput- 
ing and more specifically in applied metrology lfm[T2l . Al- 
though this domain looks simple at first glance, it involves 
nonetheless numerous fields of computer science; from low- 
level tasks like the development of drivers, protocols or state 
machines, the control of hardware, the acquisition of data, 
the synchronization of concurrent processes, or the numer- 
ical analysis and modeling of huge data sets; to high-level 
tasks like the interaction with databases or web servers, the 
management of remote or distributed resources, the visual- 
ization of complex data sets or the interpretation of scripts 
to make the system configurable and controllable by non- 
programmers |13j [14] [TSl . Not to mention that scientific 
projects commonly have to rely on sparse human resources 
to develop and maintain for the long term such continually- 
evolving-systems (i.e. R&D). Therefore the challenge is am- 
bitious but I firmly believe that COS provides the required 
features to simplify the development and the support of such 
systems as well as a wide variety of software projects. 

1.2 Principles 

Given the context, it is essential to reduce the multiplicity of 
the technologies involved, to simplify the development pro- 
cess, to enhance the productivity, to guarantee the extensibil- 
ity and the portability of the code and to adapt the required 
skills to the available resources. Hence, the qualities of the 
programming language are essential for the success of such 
projects and should focus on the following principles: 



[Copyright notice will appear here once 'preprint' option is removed.] 



' In the sense of "Lisp is a programmable programming language", (4). 
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Simplicity The language should be easy to learn and use. 
The training curve for an average programmer should be as 
short as possible what implies in particular a clear and con- 
cise syntax. Simplicity should become an asset which guar- 
antees the quality of the code and allows writing complex 
constructions without being penalized by a complex formal- 
ism or by the multiplicity of the paradigms. Cos can be 
learned within a few days by C programmers with some 
knowledge of object-oriented concepts, although exploiting 
the full power of Cos requires some experience. 

Extensibility The language should support the addition of 
new features or the improvement of existing features with- 
out changing significantly the code or the software archi- 
tecture. Concepts like polymorphism, message dispatch and 
open class model help to achieve good flexibility and exten- 
sibility by reducing coupling. But they usually have a strong 
impact on the efficiency. Cos dispatches messages with an 
efficiency in the range of the C++ virtual member functions. 

Reusability The language should support code reusability, 
namely the ability to reuse or quickly adapt existing compo- 
nents to unforeseen tasks. It is easier to achieve this goal if 
the language allows writing generic code, either by param- 
eterization, either by abstraction, to ease the componentiza- 
tion of design patterns FT6l [TTl [TSl . To support the develop- 
ment of generic components, COS provides multi-methods 
to handle dynamic and polymorphic collaboration and dele- 
gation to handle dynamic and polymorphic composition. 

Efficiency A general purpose programming language must 
be efficient, that is it must be able to translate all kinds of al- 
gorithms into programs running with predictable resource 
usage (mainly CPU and memory) consistent with the pro- 
cesses carried out. In this respect, programming languages 
with an abstract machine close to the physical machine — 
a low-level language — offer generally better results. C is 
admittedly known to achieve good efficiency. 

Portability A general purpose programming language must 
be portable, that is it must be widely available on many ar- 
chitectures and it must be accessible from almost any other 
languages (Ffi). This point often neglected brings many ad- 
vantages: it improves the software reliability, it reduces the 
deployment cost, it enlarges the field of potential users and 
it helps to find trained programmers. Regarding this point, 
no rmaZ/zet/ programming languages (ISO) get the advantage. 
ISO C89 is normalized and well known for its availability 
and portability. 

1.3 Proposition 

Cos extends the C programming language with concepts 
|fT9l mostly borrowed from Objective-C and Clos. The 
choice of designing the language as a C library instead of a 
compiler allowed to quickly explore various object models, 
but R.E. Johnson's paper on the dynamic object model ll20l 
definitely focused my research towards the final design: 



"If a system is continually changing, or if you want users 
to be able to extend it, then the Dynamic Object Model ar- 
chitecture is often useful. [...] Systems based on Dynamic 
Object Models can be much smaller than alternatives. [...] I 
am working on replacing a system with several millions lines 
of code with a system based on a dynamic object model that 
I predict will require about 20,000 lines of code. [...] This 
makes these systems easier to change by experts, and (in 
theory) should make them easier to understand and main- 
tain. But a Dynamic Object Model is hard to build. [...] A 
system based on a Dynamic Object Model is an interpreter, 
and can be slow.". 

This adaptive object model |2T'22 | is actually what Cos 
provides, but at the level of the C programming languages 
without significant efficiency loss. In particular, Cos has 
been designed to support efficiently two key concepts — 
multi-methods and fast generic delegation — and provides 
a uniform object model where classes, generics and meth- 
ods m'e first-class objects. Incidentally, Cos strengthens in- 
herently all the guidelines stated in li23J to build 'fiexible, 
usable and reusable object-oriented frameworks" as well 
as architectural pattern proposed in [24] to design flexible 
component-based frameworks. 

2. Overview 

Cos is a small framework entirely written in portabl^ 
C99 which provides programming paradigms like objects, 
classes, metaclasses, generic functions, multi-methods, del- 
egation, properties, exceptions, contracts and closures. CoS 
syntax and features are directly available at the C source 
code level through the use of the language keywords defined 
in the header file <cos/Object .h>. 

2.1 Concepts 

Polymorphism This concept available in object-oriented 
programming languages is the heart of software extensibil- 
ity because it postpones to runtime the resolution of methods 
invocation and reduces coupling between callers and callees. 
Besides, if the polymorphic types are dynamic, the coupling 
becomes almost inexistent and code size and complexity 
are significantly reduced. On one hand, these simplifications 
usually improve the programmer understanding who makes 
less conceptual errors, draws simpler designs and increases 
its productivity. On the other hand, dynamic typing post- 
pones the detection of unknown messages at runtime, with 
the risk to see programs ending prematurely. But well tested 
software reduce this risk to exceptional situations. 

Collaboration Software development is mainly about build- 
ing collaborations between entities, namely objects. As soon 
as polymorphic objects are involved everywhere to ensure 
good software extensibility and reusability, one needs poly- 
morphic collaboration implemented by multi-methods. They 

^ Namely C89 and C99 variadic macros. 
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reduce strong coupling that exist in the Visitor pattern (or 
equivalent) as well as the amount of code needed to achieve 
the task. Cos provides message multi-dispatch with an effi- 
ciency in the range of the C++ virtual member function. 

Composition The composition of objects and behaviors is 
a well known key-concept in software design. It enhances 
software flexibility by introducing levels of indirection in 
objects and behaviors. Most structural and behavioral design 
patterns described in |28| introduce such indirections, but at 
the price of an increased code complexity and coupling and 
hence a decreased reusability of the components built. The 
delegation is an effective mechanism which allows manag- 
ing the composition of both, objects and behaviors, without 
introducing coupling. Cos provides delegation with the ef- 
ficiency of message dispatch, seemingly a unique feature. 

Reflection Reflection is a powerful aspect of adaptive ob- 
ject models which, amongst others, allows to mimic the be- 
havior of interpreters. Cos provides full introspection and 
limited intercession on polymorphic types and behaviors, 
that is classes, generics and methods, as well as object at- 
tributes through the definition of properties. Since all Cos 
components are first-class objects, it is trivial to replace cre- 



ational patterns |28 | by generic functions (section 8.1 



Encapsulation Encapsulation is a major concern when de- 
veloping libraries and large-scale software. Cos enforces 
encapsulation of class implementation because encapsula- 
tion is not only a matter of managing coupling but also a 
design issue. Besides, the object behaviors are represented 
by generics which favors the separation of concerns of inter- 
faces and reduces cross-interfaces dependencies |23 |. More- 
over, the open class model of Cos allows extending classes 
on need without breaking the encapsulation (i.e. without "re- 
opening the box") and reduces the risk of premature design. 

Ownership The management of object life cycles requires 
a clear policy of ownership and scope rules. In languages like 
C and C++ where semantic by value prevails, the burden is 
put on the programmer's shoulders. In languages like Java, 
C# and D where semantic by reference prevails, the burden 
is put on the garbage collector In this domain, Cos lets the 
developer choose between garbage collection (e.g. Boehm 
GC II25I ) and manual reference counting with rich semantic 
(section |33]l. 



Concurrency Cos has been designed from the beginning 
with concurrency in mind and shares only its dictionary of 
static components. Per thread resources like message caches 
and autorelease pools rely on either thread-local-storage or 
thread-specific-key according to the availability. 

2.2 Components 

The object-oriented layer of Cos is based on three compo- 
nents (figure[T]i borrowed from Clos which characterize the 
open object model described in depth in tSJ and Ii9i . 



Function/Behavior/Verb 

defgeneric 

function declaration 
(interface) 




Tvpe/State/Noun 

def class 

structure definition 
(definition) 
1..5 



Specialization 

defmethod 

function definition 
(implementation) 



Figure 1. Roles of Cos components and their equivalent C- 
forms. Multi-methods are classes specialization of generics. 

Classes Classes play the same role as structures in C and 
define object attributes. They are bound to their superclass 
and metaclasses and define supertypes-subtypes hierarchies. 

Generics Generics play the same role as function declara- 
tions in C and define messages. They are essential actors of 
code extensibility and ensure correctness of formal parame- 
ters of messages between callers and callees. 

Methods Methods play the same role as function defini- 
tions in C and define specializations of generics. A method 
is invoked if the message belongs to its generic and the re- 
ceivers match its classes (multi-methods). 

The similarities between Cos components and their equiv- 
alent C-forms let C programmers with some notions of 
object-oriented design be productive rapidly. The open ob- 
ject model allows defining components in different places 
and therefore requires an extra linking iteration to collect 
their external symbols: link collecjj re-link. This fast 
iteration is automatically performed by the makefiles com- 
ing with Cos before the final compilation stage that builds 
the executable or the dynamic library. 

2.3 Syntax 

Cos introduces new keywords to extend the C language with 
a user-friendly syntax half-way between Objective-C and 
Clos. Cos parses its syntax and generates code with the 
help of its functional C preprocessing librarj^ a module of 
a few hundred C macros which was developed for this pur- 
pose. It offers limited parsing capabilities, token recognition, 
token manipulation and algorithms like eval, map, filter, fold, 
scan, split borrowed from functional languages and working 
on tuples of tokens. As a rule of thumb, all Cos symbols 
and macros are mangled to avoid unexpected collisions with 
other libraries, including keywords which can be disabled. 

Despite of its dynamic nature, Cos tries hard to detect 
all syntax errors, type errors and other mistakes at compile- 

^ Cos mangled symbols are collected with the nm command or equivalent. 
^ The description of this cpp library is beyond the scope of this paper. 
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time by using static asserts or similar tricks and to emit 
meaningful diagnostics. The only point that Cos cannot 
check at compile time is the understanding of a message by 
the receivers; an important "feature" to reduce coupling. 

The syntax and grammar of Cos are summarized in the 
figures |2) |7] [8] |9] [To] and [11] following the notation of the 
C99 standard d- 

3. Classes («0H«s) 

Cos allows defining and using classes as easily as in other 
object-oriented programming languages. 

3.1 Using classes 

The useclassO declaration allows accessing to classes as 
first-class objects. The following simple program highlights 
the similarities between Cos and Objective-C: 

1 #include <cos/Object .h> 

2 #include <cos/generics .h> 

3 

4 useclass (Counter , (Stdout)out) ; 

5 

6 int main (void) { 

7 QBJ cnt = gnew (Counter) ; 
s gput (out , cnt) ; 

9 gdelete (cnt) ; 

10 } 

which can be translated Hne-by-line into Objective-C by: 

1 #include <objc/Object .h> 

2 // Counter interface isn 't exposed intentionally 

3 

4 Sclass Counter, Stdout; 

5 

6 int main (void) { 

7 id cnt = [Counter new] ; 

8 [Stdout put : cnt] ; 

9 [cnt release] ; 

10 } 

Line [2] makes the standard generics like gnew, gput and 
gdelet^visible in the cuiTent ti-anslation unit. Objective- 
C doesn't need this information since methods are bound 
to their class, but if the user wants to be warned for incor- 
rect use of messages, the class definition must be visible. 
This example shows that Cos requires less information than 
Objective-C to handle compile-time checks what leads to 
better code insulation and reduces useless recompilations. 
Moreover, it offers fine tuning of exposure of interfaces since 
only the used generic functions have to be visible. 

Line ID declares the class Countei[3and the alias out for 
local replacement of the class Stdout, both classes being 
supposedly defined elsewhere. In line[7| the generic type OBJ 
is equivalent to id in Objective-C. 

^ By convention, the name of generics always starts by a 'g'. 

* By convention, the name of classes always starts by an uppercase letter 



class-declaration: 

useclass ( class-decl-list ) ; 

class-decl-list: 
class-decl 

class-decl-list , class-decl 

class-decl: 
class-name 

( class-name ) local-name 

class-definition: 

def class ( class-specifier ) 
^ struct-declaration-list (c99) 
^ endclass 

class-instantiation: 

makclassC class-specifier ) ; 

class-specifier: 
class-name 

class-name , _ (root class) 

class-name , superclass-name 

{class, superclass, local}-name: 

identifier (c99) 



Figure 2. Syntax summary of classes. 

Lines [7] - [9] show the life cycle of objects, starting with 
gnew (resp. new) and ending with gdelete (resp. release). 
They also show that generics are functions [e.g. one can 
take their address). Finally, the line [8] shows an example of 
multi-method where the message gput(_,_) will look for 
the specialization gput (mStdout .Cotmter) whose meaning 
is discussed in section [5] In order to achieve the same task, 
Objective-C code has to rely on the Visitor pattern, a bur- 
den that requires more coding, creates static dependencies 
(strong coupling) and is difficult to extend. 

3.2 Defining classes 

The definition of a class is very similar to a C structure: 

def class (Counter) 

int cnt ; 
endclass 

which is translated in Objective-C as: 

8interface Counter : Object { 
int cnt ; 

} 

// declaration of Counter methods not shown 
Send 

or equivalently in Clos as: 
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NIL 




•- subclass of 



NIL 




Method j ^ Behavior^ Proxy j | ^ Property j Predicate^ 




TrueFalse 



True 



False 



^ PropMetaClass 



Figure 3. Subset of COS core classes hierarchy. 

(def class Counter (Object) ((cnt)) ) 

The Counter class derives from the root class Object — the 
default behavior when the superclass isn't specified — and 
defines the attribute cnt. 

Class visibility What must be visible and when ? In order 
to manage coupling, Cos provides three levels of visibility: 
none, declaration and definition. If you only use the generic 
type OBJ, nothing is required (no coupling): 

OBJ gnew(OBJ els) i 

return ginit (galloc (els) ) ; 

> 

If you want to create instances of a class, only the declaration 
is required (weak coupling): 

OBJ gnewBook(void) { 

useclass (Book) ; // local declaration 
return gnew(Book) ; 

} 

If you want to define subclasses, methods or instances with 
automatic storage duration, the class definition must be visi- 
ble (strong coupling). 

3.3 Class inheritance 

Class inheritance is as easy in COS as in other object- 
oriented programming languages. Figure |3] shows the hi- 
erarchies of the core classes of Cos deriving from the root 
classes Object and Nil. As an example, the MilliCounter 
class defined hereafter derives from the class Coimter to 
extend its resolution to thousandths of count: 

def class (MilliCounter , Counter) 

int mcnt ; 
endclass 



which gives in Objective-C: 

Qinterface MilliCounter 
int mcnt : 



Counter -[ 



// declaration of MilliCounter methods not shown 
Send 

and in Clos: 

(def class MilliCounter (Counter) ((mcnt)) ) 

In the three cases, the derived class inherits the attributes and 
the methods of its superclass. Since Cos aims at insulating 
classes as much as possible, it discourages direct access to 
superclass attributes by introducing a syntactic indirection 
which forces the user to write obj->Super. attribute in- 
stead of obj-> attribute. The inheritance of multi-methods 
has a different meaning and will be discussed in section |5] 

Root class Defining a root class is an exceptional task but it 
may be a necessity in some rare cases. Cos uses the terminal 
symbol _l|^ (represented by '_') to declare a class as a root 
class. For example. Object is an important root class with 
the following simple definition: 

def class (Object , _) 

U32 id; // object's class identity 

U32 rc; // reference counting 
endclass 

But its methods must be defined with care since they provide 
all the essential functionaUties inherited by other classes. 

Class rank Cos computes at compile-time the inheritance 
depth of each class. The rank of a root class is zero (by 
definition) and each successive subclass increases the rank. 

Dynamic inheritance Cos provides the message gchange- 
Class (,obj , els) to change the class of ohj to els iff it is a 
superclass of ohfs class; and the message gunsaf eChange- 
Class (.obj , els ,spr) to change the class of ohj to els iff both 
classes share a common superclass spr and the instance size 
of els is lesser or equal to the size of ohj. These messages are 
useful for implementing class clusters, state machines and 
adaptive behaviors. 

3.4 Meta classes 

Like in Objective-C, a Cos class definition creates a 
parallel hierarchy of metaclass which facilitates the use of 
classes as first-class objects. Figure |4] shows the complete 
hierarchy of the PropMetaClass class, including its meta- 
classes. 

Class metaclass The metaclasses are classes of classes im- 
plicitly defined in Cos to ensure the coherency of the type 
system: to each class must correspond a metaclass f26l. Both 
inheritance trees are built in parallel: if a class A derives from 
a class B, then its metaclass mj|^derives from the metaclass mB 
— except the root classes which derive from NIL and have 
their metaclasses deriving from Class to close the inheri- 
tance path. Metaclasses are instances of the class MetaClass. 

' ± means "end of hierarchy" or NIL, but not the class Nil. 
* The metaclass name is always the class name prefixed by a 'm' . 
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NIL 



' subclass of 



^ PropMetaClass j >| pmProplVletaClass 



Figure 4. Cos core classes hierarchy with metaclasses. 



Property metaclass In some design patterns Hke Singleton 



or Class Cluster, or during class initialization (section 3.6 1, 
the automatic derivation of the class metaclass from its su- 
perclass metaclass can be problematic as detailed in 12711 . 
To solve the problem Cos associates to each class a prop- 
erty metaclass which cannot be derived; that is all methods 
specialized on the property metaclass can only be reached 
by the class itself. In order to preserve the consistency of 
the hierarchy, a property metaclass must always derive from 



its class metaclass, namely pmiT 
(resp. mB) as shown in the figure 



(resp. pmB) derives from mA 
4l Property metaclasses are 



instances of the class PropMetaClass. 

Class objects With multi-methods and metaclasses in 
hands, it is possible to use classes as common objects. Fig- 
ure |5] shows the hierarchy of the core class-objects used 
in Cos to specialized multi-methods with specific states. 
For instance messages like gand, gor and gnot are able to 
respond to messages containing the class-predicates True, 
False and TrueFalse. The root class Nil is a special class- 
object which means no-object but still safe for message dis- 
patch: sending a message to Nil is safe, but not to NIL. 

Type system The Cos type system follows the rules of 
Objective-C, that is polymorphic objects have opaque 
types (ADT) outside their methods and are statically and 
strongly typed inside; not to mention that multi-methods re- 
duce significantly the need for runtime identification of poly- 
morphic parameters. Furthermore, the set of class - meta- 
class - property-metaclass forms a coherent hierarchy of 
classes and types which offers better consistency and more 
flexibility than in Objective-C and SMALLTALK where 
metaclasses are not explicit and derive directly from Object. 




[ True j False j [ ^Lesserj Equal j 'y Greater ^ 



' The property metaclass name is always the class name prefixed by a 'pm'. 



Figure 5. Subset of Cos core class-predicates hierarchy. 



3.5 Class instances 

Object life cycle The life cycle of objects in Cos is very 
similar to other object-oriented programming languages, 
namely it starts by creation (galloc) followed by initial- 
ization (ginit and variants) and ends with deinitialization 
(gdeinit) followed by destruction (gdealloc). In between, 
the user manages the ownership of objects {i.e. dynamic 
scope) with gretain, grelease and gautoRelease like in 
Objective-C. The copy initializer is the specialization of 
the generic ginitWith(_,_) for the same class twice. The 
designated initializer is the initializer with the most cover- 
age which invokes the designated initializer of the superclass 
using next .method. Other initializers are secondary initial- 
izers which must invoke the designated initializer |7 |. 

Object type In Cos (resp. Objective-C), objects ai-e al- 
ways of dynamic type because the type of galloc (resp. 
alloc) is OBJ (resp. id). Since it is the first step of the life cy- 
cle of objects in both languages, the type of objects can never 
be known statically, except inside their own multi-methods. 
That is why Cos (resp. Objective-C) provides the mes- 
sage gisKindDf(o^)/,c/.s) (resp. iobj isKindOf: c/j]) to in- 
spect the type of objects. But even so, it would be danger- 
ous to use a static cast to convert an object into its expected 
type because dynamic design patterns like Class Cluster and 
Proxy might override gisKindOf for their use. Cos also pro- 
vides the message gclassCofcJ) which returns oZ?/s class. 

Object identity In Cos, an object is bounded to its class 
through a unique 32-bit identifier produced by a linear con- 
gruential generator which is also a generator of the cyclic 
groups N/2'^N for k = 2. .32. This powerful algebraic prop- 
erty allows retrieving efficiently the class of an object from 
the components table using its identifier as an index (Fig- 
ure |6]). Comparing to pointer-based implementations, the 
unique identifier has four advantages: 

It ensures better behavior of cache lookups under heavy 
load (uniform hash), it makes the hash functions very fast 
(sum of shifted idsj, it is smaller than pointers on 64-bit 
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Dictionary of behavioral components 



obj->id 



obfs class 



table [ofo/->id & (table_size-l)] 



Class initialization For the purpose of pre-initialization, 
Cos ensures to invoke once by ascending class rank (super- 
class first) all specializations of the message ginitialize 
on property metaclass before the first message is sent. Like- 
wise, Cos ensures to invoke once by descending class 
rank (subclasses first) all specializations of the message 
gdeinitialize on property metaclass after exiting main. 



Figure 6. Lookup to retrieve object's class from object's id. ^' Generics (verbs) 



machines and it can store extra information (high bits) like 
class ranks to speedup linear lookup in class hierarchies. 

Automatic objects Since Cos adds an object-oriented 
layer on top of the C programming language, it is possible 
to create objects with automatic storage duration (e.g. on the 
stack) using compound literals (C99). In order to achieve 
this, the class definition must be visible and the developer 
of the class must provide a special constructor For exam- 
ple the constructor aStrC'a string" )[^is equivalent to the 
Objective-C directive ®"a string". Cos already pro- 
vides automatic constructors for many common objects like 
Char, Short, Int, Long, Float, Complex, Range, Functor and 
Array. Automatic constructors allow creating efficiently tem- 
porary objects with local scope and enhance the flexibility of 
multi-methods. For example, the initializer ginitWith(_,_) 
and its variants can be used in conjunction with almost all 
the automatic constructors aforementioned. Thanks to the 
rich semantic of Cos reference counting, if an automatic 
object receives the message gretain or gautoDelete, it is 
automatically cloned using the message gclone and the new 
copy with dynamic scope is returned. 

Static objects Static objects can be built in the same way 
as automatic objects except that they require some care in 
multi-threaded environments. It is worth to note that all Cos 
components have static storage duration and consequently 
are insensitive to ownership and cannot be destroyed. 

3.6 Implementing classes 

Class instantiations create the class objects using the key- 
word makclass and the same class-specifier as the corre- 
sponding def class. Cos checks at compile-time if both 
definitions match. The counters implementation follows; 

makclass (Counter) ; 

makclass (MilliCounter, Counter) ; 

which is equivalent in Objective-C to: 

Simplementation Counter 

// definition of Counter methods not shown 
Send 

Oimplementation MilliCounter : Counter 
// definition of MilliCounter methods not shown 
Send 



We have already seen in previous code samples that generics 
can be used as functions. But generics take in fact multiple 
forms and define each: 

• a. function declaration (def generic) which ensures the 
correctness of the signature of its methods (def method), 
aliases (def alias) and next-methods (defnext). 

• a. function definition used to dispatch the message and to 
find the most specialized method belonging to the generic 
and matching the classes of the receivers. 

• an object holding the generic's metadata: the selector. 

A generic function has one definition of its semantics and is, 
in effect, a verb raised at the same level of abstraction as a 
noun |4|. Figure |7] summarizes the syntax of generics, half 
way between the syntax of generic's definition in Clos and 
the syntax of method's declaration in Objective-C. 

Generic rank The rank of a generic is the number of re- 
ceivers in its param-list. Cos supports generics from rank 
1 to 5 what should be enough in practice since rank 1 to 4 
already cover all the multi-methods defined in the libraries 
of Cecil and Dylan 1 



' By convention, automatic constructors always starts by an 'a'. 



4.1 Message dispatch 

Cos dispatch uses global caches (one per generics rank) 
implemented with hash tables to speedup method lookups. 
The caches solve slot collisions by growing until they reach 
a configurable upper bound of slots. After that, they use 
packed linked list incrementally built to hold a maximum of 
3 cells. Above this length, the caches start to forget cached 
methods — a required behavior when dynamic class creation 
is supported. The lookup uses fast asymmetric hash func- 
tions (sum of shifted ids) to compute the cache slots and en- 
sures uniform distribution even when all selectors have the 
same type or specializations on permutations exist. 

Fast messages Cos lookup is simple enough to allow 
some code inlining on the caller side to speedup message 
dispatch. Fast lookup is enabled up to the generic rank spec- 
ified by COS_FAST_MESSAGE — from disabled (0) to all (5, 
default) — before the generic definitions (def generic). 

4.2 Declaring generics 

Generic declarations are less common than class declara- 
tions but they can be useful when one wants to use gener- 
ics as first-class objects. Since generic definitions are more 
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generic-declaration: 

usegenericC generic-decl-list ) ; 

generic-decl-list: 
generic-decl 

generic-decl-list , generic-decl 

generic-decl: 
generic-name 

( generic-name ) local-name 

generic-definition: 

def generic ( generic-specifier ) ; 

generic-variadic-definition: 

def genericvC generic-specifier , . . . ) ; 

generic-specifier: 

return-type , generic-def , param-list 

generic-def: 
generic-name 

( class-name ) generic-name 

param-list: 
param-decl 

param-list , param-decl 

param-decl: 

param-namcopt 

( param-type ) param-name 

{return, param}-type: 
type-name 

{generic, param{-name: 
identifier 



(selector) 

(c99) 
(c99) 



4.3 Defining generics 

Definitions of generics correspond to function declarations 
in C and differ from Objective-C method declarations by 
the fact that they are neither bound to classes (prefix '-') nor 
to metaclasses (prefix '+'). The following definitions: 

def generic (void, gincr, _1) ; // rank 1 

def generic (void , gincrBy, _1, (int)by) ; // rank 1 

def generic (OBJ , ginitWith, _1, _2) ; //rank! 

def generic (OBJ , ggetAt , _1, at); //rank! 

def generic (void , gputAt , _1, at, what); // rank 3 

can be translated into Clos as: 

(def generic incr (obj)) 
(def generic incr-by (obj by)) 
(def generic init-with (obj with)) 
(def generic get-at (obj at)) 
(def generic put-at (obj at what)) 

Selector parameters like at are called open types (no paren- 
thesis) since their type can vary for each specialization. 
Other parameters like by are called closed types (with paren- 
thesis) and have fixed types and names: specializations must 
use the same types and names as defined by the generic. This 
enforces the semantic of monomorphic parameters which 
could be ambiguous otherwise: int off set v.?. int index. 

5. Methods 

Methods are defined using a similar syntax as generics 
as summarized in figure [8] The following code defines a 
method specialization of the generic gincr for the class 
Counter: 



def method (void, 

self->cnt++; 
endmethod 



gincr. Counter) 



Figure 7. Syntax summary of generics. 



which in OBJECTIVE-C gives (within aimplementation): 

- (id) incr { 
self->cnt++; 



often visible than class definitions, it is common to rename 
them locally as in the following short example: 

void saf e_print (OBJ obj) { 
usegeneric( (gprint) prn ); 

if ( gunderstandMessagel (obj , prn) == True ) 
gprint (obj) ; 

} 

which gives in Objective-C: 

void saf e_print (id obj) { 
SEL prn = Sselector (print) ; 
if ( [obj respondsToSelector : prn] == YES ) 
[obj print] ; 

} 



Methods specializers The receivers can be equivalently 
accessed through self yp] whose types correspond to their 
class specialization (e.g. struct Counter*) and through un- 
named parameters _« whose types are OBJ for I < n < g, 
where g is the rank of the generic. It is important to under- 
stand that self n and _n are bound to the same object, but 
self n provides a statically typed access which allows treat- 
ing Cos objects like normal C structures. 

Multi-methods Multi-methods are methods with more 
than one receiver and do not require special attention in 
Cos. The following example defines the assign-sum opera- 
tor (i.e. +=) specializations which adds 2 or 3 Counters: 

" self and self 1 are equivalent. 
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def method (OBJ , gaddTo, Counter, Counter) 

self->cnt += self2->cnt; 

retmethod(_l) ; // return self 
endmethod 

def method (OBJ , gaddTo2, Counter .Counter .Counter) 
self->cnt += self2->cnt + self3->cnt; 
retmethod(_l) ; // return self 

endmethod 



About half of Cos generics have a rank > 1 (multi-methods) 
and cover more than 80% of all the methods specializations. 



Class methods Class methods are methods speciahzed for 
classes deriving from Class what includes all metaclasses: 

def method (void, ginitialize, pmMyClass) 

// do some initialization specific to MyClass. 
endmethod 

def method (OBJ , gand, mTrue. mFalse) 

retmethod (False) ; // return the class— object False 
endmethod 

Method aliases Cos allows specializing compatible gener- 
ics with the same implementation. The following aliases de- 
fine specializations for gpush, gtop and gpop which share 
the specializations of gput, gget and gdrop respectively: 

def alias (void . (gput )gpush. Stack. Object); 
defalias(OBJ . (gget )gtop , Stack. Object); 
def alias (void . (gdrop) gpop , Stack. Object); 

Method types In order to support fast generic delegation 



(section 5.2 1, Cos must use internally the same function 
types (i.e. same C function signatures) for methods imple- 
mentation belonging to generics of the same rank: 

void (*IMP1) (SEL. OBJ. void*, void*) ; 
void (*IMP2) (SEL. OBJ. OBJ, void*. void*) ; 
void (*IMP3) (SEL. OBJ. OBJ, OBJ, void*, void*) ; 

The first parameter _sel is the message selector (i.e. generic's 
object) used by the dispatcher, the OBJs _n are the objects 
used as selectors (i.e. receivers) by the dispatcher, the penul- 
timate parameter _arg is a pointer to the structure storing 
the closed arguments of the generic (if any) and the last pa- 
rameter _ret is a pointer to the placeholder of the returned 
value (if any). The responsibilities are shared as follow: 

• The generic functions are in charge to pack the closed 
arguments (if any) into the structure pointed by _arg, to 
create the placeholder pointed by _ret for the returned 
value (if any), to lookup for the method specialization and 
to invoke its implementation (i.e. IMPn) with the prepared 
arguments _sel, _n, _arg and _ret. 

• The methods are in charge to unpack the closed argu- 
ments into local variables and to handle the returned 
value appropriately. 



method-definition: 

def method ( method-specifier ) 
^ method-statement 
^ endmethod 

method-specifier: 

return-type , method-def , param-list 

method-def: 
generic-name 

( generic-name ) tag-namCopt 



( around method) 



method-statement: 

compound-statement ( c99) 

compound-statement-with-contract ( contract) 

method-return-statement: 

retmethod ( expressiongp, ) ; 

method-alias-definition: 

def alias ( generic-specifier ) ; 

alternate-next-method-definition: 
def next ( generic-specifier ) ; 

next-method-statement: 

next_method( argument-expression-list ) ; 

forward-message-statement: 

f orwardjnessage ( argument-expression-list ) ; 

Figure 8. Syntax summary of methods. 
5.1 Next method 

The next .method principle borrowed from Clo^^ is an 
elegant answer to the problem of superclass(es) methods 
call (i.e. late binding) in the presence of multi-methods. 
The following sample code defines a specialization of the 
message gincrBy for the class MilliCounter which adds 
thousandths of count to the class Counter: 

1 def method (void, gincrBy. MilliCounter, (int)by) 

2 self->mcnt += by; 

3 if (self->mcnt >= 1000) ■[ 

4 def next (void , gincr, MilliCounter); 

5 self->mcnt -= 1000; 

6 next_method(self ) ; // call gincr( Counter) 

y 

s endmethod 

which is equivalent to the Objective-C code: 

- (void) incrBy: (int)by { 
self->mcnt += by; 
if (self->mcnt >= 1000) I 



-Namely call-next -method. 
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self->mcnt -= 1000; 
[super incr] ; 

} 

} 

Line [6] shows how Cos next .method replaces the message 
sent to super in Objective-C. By defauh, next .method 
calls the next method belonging to the same generic (e.g. 
gincrBy) where next means the method with the highest spe- 
cialization less than the current method. But in the example 
above, the Counter class has no specialization for gincrBy. 
That is why the line [4] specifies an alternate next method 
path, namely gincr, to redirect the next .method call to the 
appropriate next method. In some cases, it might be safer to 
test for the existence of the next method before calling it: 

if (next_method_p) next .method (self ) ; 

It is worth to note that next .method transfers the returned 
value (if any) directly from the called next method to the 
method caller. Nevertheless, the returned value can still be 
accessed through the lvalue RETVAL. 

Methods specialization Assuming for instance the class 
inheritance A :> B :> C, the class precedence list for the 
set of all pairs of specialization of A, B and C by decreasing 
order will be: 

(C,C) (C,B) (B,C) (C,A) (B,B) (A,C) (B,A) (A,B) (A, A) 

and the list of all next .method paths are: 

(C,C)(C,B)(C,A)(B,A)(A,A) 
(B.C)(B.B)(B.A)(A,A) 
(A,C) (A,B) (A, A) 

The algorithm used by Cos to build the class precedence 
list {i.e. compute methods rank) has some nice properties: it 
provides natural asymmetric left-to-right precedence and it 
is non-ambiguous, monotonic and totally ordered 1351 . 

Around methods Around methods borrowed from Clos 
provide an elegant mechanism to enclose the behavior of 
some primary method by an arbitrary number of around 
methods. Around methods are always more specialized than 
their primary method but have an undefined precedence: 

def method (void, gdolt. A, A) 
endmethod 

def method (void, gdolt, B, A) 

next.method(self 1 , self 2) ; // call gdoIt(A,A) 
endmethod 

def method (void, (gdolt), B, A) // around method 

next.method(self 1 , self 2) ; // call gdoIt(B,A) 
endmethod 

def method (void, gdolt, B, B) 

next.method(self 1 , self 2) ; // call (gdolt )(B, A) 
endmethod 



5.2 Delegation 

Message forwarding is a major feature of COS which was 
developed from the beginning with fast generic delegation 
in mind as already mentioned in the previous section. 

Unrecognized message Message dispatch performs run- 
time lookup to search for method specializations. If no spe- 
cialization is found, the message gunrecognizedMessagen is 
SUBSTITUTED and sent with the same arguments as the orig- 
inal sending, including the selector. Hence these messages 
can be overridden to support the delegation or some adaptive 
behaviors. The default behavior of gunrecognizedMessagen 
is to throw the exception ExBadMessage. 

Forwarding message Message forwarding has been bor- 
rowed from Objective-C and extended to multi-methods. 
The sample code below shows a common usage of message 
forwarding to protect objects against invaUd messages: 

1 def method (void, gunrecognizedMessagel , MyProxy) 

2 if (gundertstandMessagel (self ->obj ,.sel)==True) 

3 f orward.message (self ->obj ) ; //delegate 

4 endmethod 

which can be translated Hne-by-line into Objective-C by: 

1 - (retval_t) forward: (SEL)sel : (arglist_t)args { 

2 if ([self->obj respondsTo: sel] == YES) 

3 return [self->obj perf ormv: sel :args]; 

4 } 

Here, f orward.message propagates all the arguments, in- 
cluding the hidden parameters .sel, .arg and .ret, to a 
different receiver. As for next .method, f orward.message 
transfers the returned value directly to the method caller and 
can be accessed through RETVAL in the same way. 

Fast delegation Since all methods belonging to generics 
with equal rank have the same C function signature and fall 
into the same lookup cache, it is safe to cache the message 
gunrecognizedMessagen in place of the unrecognized mes- 
sage. Hence, the next sending of the latter will result in a 
cache hit. 

This substitution allows the delegation to be as fast as 
message dispatch, seemingly a unique feature. 



Intercession of forwarded messages Since the closed ar- 
guments of the generic's param-list are managed by a C 
structure, it is possible to access each argument separately. 
In order to do this, Cos provides introspective information 
on generics (i.e. metadata on types and signatures) which 
allows identifying and retrieving the arguments and the re- 
turned value efficiently. But this kind of needs should be ex- 
ceptional and is beyond the scope of this paper. 

5.3 Contracts 

To quote Bertrand Meyer lISTl . the key concept of Design 
by Contract is ''viewing the relationship between a class and 
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compound-statement-with-contmct: 

declamtion-without-initializer ( c99 ) 

^ pre-statementopt post-statementopt body-statement 

pre-statement: 
PRE statement 

post-statement: 
POST statement 

body-statement: 
BODY statement 

test-assert-statement: 

test_assert( bool-expr ) 

test_assert( bool-expr , cstr ) 

test .assert ( bool-expr , func , file , line ) 

test .assert ( bool-expr , cstr , func , file , line ) 

tes t- inva riant-statemen t: 

test_invariaiit ( object-expr ) 
test-invariant ( object-expr , func , file , line ) 



Figure 9. Syntax summary of contracts. 

its clients as a formal agreement, expressing each party's 
rights and obligations" . Most languages that support Design 
by Contract provide two types of statements to express the 
obHgations of the caller and the callee: preconditions and 
postconditions. The caller must meet all preconditions of 
the message sent, and the callee (the method) must meet its 
own postconditions — the failure of either party leads to a 
bug in the software. In that way. Design by Contract (i.e. 
developer point of view) is the complementary tool of Unit 
Testing |42| (i.e. user point of view) and they both enhance 
the mutual confidence between developers and users, help to 
better identify the responsibilities and improve the design of 
interfaces. 

To illustrate how contracts work in Cos with the syntax 
summarized in figure [9] we can rewrite the method gincr: 

def method (void, gincr, Counter) 

int old_cnt; // no initializer! 

PRE old_cnt = sslf->cnt; 

POST test_assert(sGlf->cnt < old_cnt) ; 

BODY self->cnt++; 
endmethod 

The POST Statement test_assert checks for counter over- 
flow after the execution of the BODY statement and throws 
an ExBadAssert exception on failure, breaking the contract. 
The variable old_val initialized in the PRE statement before 
the execution of the BODY statement, plays the same role as 
the old feature in EIFFEL. As well gincrBy can be improved; 



def method (void, gincrBy, MilliCounter , (int)by) 
PRE test.assert (by >= M by < 1000, 

"millicount out or range"); 
BODY // same code as before 

endmethod 

The PRE Statement ensures that the incoming by is within 
the expected range and the next_method call in the BODY 
statement ensures that the contract of gincr is also fulfilled. 

Assertions and tests In order to ease the writing of con- 
tracts and unit tests, COS provides two standard tests: 

• test_aLSsert(.expr[,str'] [,func , file , line']) is a replace- 
ment for the standard assert and raises an ExBadAssert 
exception on failure. The (optional) parameters str, func, 
file and line are transfered to THROW for debugging. 

• test_invariant (ofoy'[,/"nc,^7e,/Hie] ) checks for the 
class invariants of objects. It can only be used inside 
methods and is automatically invoked on each receiver if 
the invariant contract level is active. The (optional) pa- 
rameters /m«c, ^Ze and line are transfered to ginvariatit. 

Class invariants The test_invariant assertion relies on 
the message ginvariant which must be specialized for 
MilliCounter to be effective in the previous example: 

def method (OBJ , ginvariant, MilliCounter, 

(STR)func, (STR)file, (int)line) 

next .method (self ) ; // check Counter invariant 

int mcnt = self->mcnt; 

test_assert (mcnt >= && mcnt < 1000, 

"millicount out of range", func, file, line); 
endmethod 

Here, test_assert propagates the location of the calling 
test_invariant to improve bug tracking. 

Contracts and inheritance In the design of EIFFEL, Ber- 
trand Meyer recommends to evaluate inherited contracts as 
a disjunction of the preconditions and as a conjunction of 
the postconditions. But 1321 demonstrates that ElFFEL-style 
contracts may introduce behavioral inconsistencies with in- 
heritance, thus Cos prefers to treat both pre and post con- 
ditions as conjunctions. This is also the only known solu- 
tion compatible with multi-methods where subtyping is su- 
perseded by the class precedence list. 

Contracts levels The level of contracts can be set by defin- 
ing the macro COS_CONTRACT to one of the levels: 

• NO disable contracts (not recommended). 

• COS_CONTRACT_PRE enables PRE sections. This is the rec- 
ommended level for production phases (default level). 

• COS_CONTRACT_POST enables PRE and POST sections. This 
is the usual level during the development phases. 

• COS_CONTRACT_ALL enables PRE and POST sections as wefl 
as test_invariant Statements. This is the highest level 
usually set during debugging phases. 
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property-declaration: 

usepropertyC property-decl-list ) ; 

property-decl-list: 
property-decl 

property-decl-list , property-decl 

property-decl: 
property-name 

( property-name ) local-name 

property-definition: 

def property ( property-def) ; 

property-def: 
property-name 

( super-property-name ) property-name 

class-property-definition: 

def property ( class-property-def ) ; 

class-property-def: 

class-name , property-attr 
class-name , property-attr , get-funCopt 
class-name , property-attr , get-fimCopt > put-funcopt 

property-attr: 
property-name 

( object-attribute opt) property-name 

{property, super-property}-name, object-attribute: 

identifier (c99) 

Figure 10. Syntax summary of properties. 
5.4 Properties 

Property declaration is a useful programming concept which 
allows, amongst others, to manage the access of object at- 
tributes, to use objects as associative arrays or to make ob- 



jects persistent. Figure 10 summarizes the syntax of proper- 
ties in Cos which are just syntactic sugar on top of the defi- 
nition of class-objects and the specialization of the accessors 



ggetAt and gputAt already mentioned in section 4.3 



Property definition Properties in Cos are defined conven- 
tionally with lowercase names: 

def property ( name ) ; 
def property ( size ) ; 
def property ( class ); 
def property ( value ); 

For example, the last property definition is equivalent to: 

def class (P_value , Property) 
endclass 



Most notably, properties are class-objects deriving from the 
class Property (fig.|3]l with lowercase names prefixed by P_. 

Class properties Once properties have been defined, it is 
possible to define some class-properties: 

def property (Counter , (cnt)value, int20BJ, gint) ; 
def property (Counter , Oclass, gclass) ; 

with: 

QBJ int20BJ(int val) { // cannot be a method 
return gautoDelete (aint (val) ) ; 

} 

The value property is associated with the cnt attribute with 
read-write semantic and uses user-defined boxing (int20BJ) 
and unboxing (gint). The class property is associated with 
the entire object (omitted attribute) with read-only semantic 
and uses the inherited message gclass to retrieve it. 

Sometimes the abstraction or the complexity of the prop- 
erties require handwritten methods. For instance: 

def method (OBJ , ggetAt, Person, mP_naine) 

retmethod(gcat(self->f stname, self ->lstnaine) ) ; 
endmethod 

is equivalent to, assuming gname (Person) is doing the gcat: 
def property (Person, Oname, gname); 

Using properties The example below displays the name 
property of an object (or raise the exception ExBadMessage): 

void print_name (QBJ ob j ) { 
useproperty (name) ; 
gprint (ggetAt (obj , name) ) ; 

6. Exceptions 

Exceptions are non-local errors which ease the writing of 
interfaces since they allow solving the problems where the 
solutions exist. To state it differently, if an exceptional con- 
dition is detected, the callee needs to return an error and let 
the caller take over. Applying recursively this behavior re- 
quires a lot of boilerplate code on the callers side to check 
returned status. Exceptions let the callers choose to either 
ignore thrown errors or to catch them and take over. 

Implementing an exception mechanism in C on top of the 
standard setjmp and longjmp is not new. But it is uncom- 
mon to see a framework written in C which provides the 



full try-catch-finally statements (figure 1 1 1 with the same se- 
mantic as in other object-oriented programming languages 
{e.g. Java, C#). The catch declaration relies on the mes- 
sage gisKindOf to identify the thrown exception, what im- 
plies that the order of CATCH definitions matters, as usual. 

The sample program hereafter gives an overview of ex- 
ceptions in Cos: 

1 int main(void) ■[ 

2 useclass (String, ExBadAssert, mExBadAlloc) ; 
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try-statement: 
TRY 

^ statement 
^ catch- statement-list opi 
^ finally-statementopt 
^ ENTRY 

catch-statement-list: 
catch-statement 

catch- statement-list catch-statement 

catch-statement: 

CATCH ( class-name , exception-name opt ) statement 
CATCH JINY( exception-namCopt ) statement 

finally-statement: 

FINALLY statement 

throw-statement: 

THROW ( object-expr ) ; 

THROW ( object-expr , func , file , line ) ; 

RETHROW () ; 



exception-name: 
identifier 



(c99) 



Figure 11. Syntax summary of exceptions. 



SIR si 
QBJ s2 



0; 

Nil; 



TRY 

si = strdupC'strl") ; 

s2 = gnewWithStr( String, "str2") ; 

test_assert (0, "throw ExBadAssert") ; 

CATCH (ExBadAssert, ex) 

printf ("assertion y,s failed (y.s,'/.d)\n" , 
gstr(ex), ex_file, ex_line) ; 

gdelete (ex) ; 
CATCH (mExBadAlloc, ex) // catcfi class ExBadAlloc 

printf ("out of memory ("/.s ,y,d)\n" , 
ex_file, ex_line) ; 

gdelete (ex) ; 
CATCH_ANY(ex) 

printf ("unexpected exception y.s (y,s,y,d)\n" , 
gstr(ex), ex_file, ex_line) ; 

gdelete (ex) ; 
FINALLY // always executed 

f ree(sl) ; 

gdelete (s2) ; 
ENDTRY 



• Line [15] catches the class ExBadAlloc which is thrown 
when a memory allocation failure occurs. Throwing an 
instance of the class in a such context would not be safe. 

• Line [23] destroys the two strings whatever happened. 
Their initial states have been set to be neutral for these 
operations in case of failure. 

Cos allows throwing any kind of object but it provides also 
a hierarchy of exceptions deriving from Exception: ExBad- 
Alloc, ExBadArity, ExBadAssert, ExBadCast, ExBadDomain, 
ExBadFormat, ExBadMessage, ExBadProperty, ExBadRange, 
ExBadSize, ExBadlype, ExBadValue, ExNotFound, ExNot- 
Implemented, ExNotSupported, ExErrno, and ExSignal. 
Among these exceptions, ExErrno and ExSignal are spe- 
cial cases used respectively to convert standard errors (i.e. 
test_errno 0) and registered signals into exceptions. 

7. Performance 

In order to evaluate the efficiency of COS, small test suite^ 
have been written to stress the message dispatcher in various 
conditions. The test results summarized in tableland fig 



have been performed on an Intel DualCore2 T9300 
CPU 2.5 Ghz with Linux Ubuntu 64-bit and the compiler 
Gcc 4.3 to compile the tests written in the three languages. 
The timings have been measured with clock () and aver- 
aged over 10 loops of 2 • 10* iterations each. The Param. 
column indicates the number of parameters of the message 
split by selectors (open types) and arguments (closed types). 
The other columns represent the performances in million of 
invocations sustained per second for respectively C-n- vir- 
tual member functions, Objective-C messages and Cos 
messages. The tests stress the dispatcher with messages al- 
ready described in this paper: incr increments a counter, 
incrBy{2 . . 5}opt accept from 1 to 5 extra closed parameters 
(to stress the construction of _arg) and addTo-[2 . . 4}-opt add 
from 2 to 5 Counters together (to stress multiple dispatch). 
Multiple dispatch has been implemented with the Visitor de- 
sign pattern in C-i-i- and Objective-C. 

Concerning the performance of single dispatch, COS 
shows a good efficiency since it runs in average at about the 
same speed as C-i-f and about x 1.6 faster than Objective- 
C. On one hand, Cos efficiency decreases faster than C++ 
effciency because it passes more hidden arguments [i.e. _sel 
and _arg) and uses more registers to compute the dispatch. 
On the other hand, C++ shows some difficulties to manage 
efficiently multiple inheritance of abstract classes. Concern- 
ing the performance of multiple dispatch, Cos outperforms 
C++ and Objective-C by factors x 1.9 and x 5.3. Concern- 
ing the performance of message forwarding, we have seen 
that by design, it runs at the full speed of message dispatch 
in Cos. Rough measurements of Objective-C message 
forwarding (linear lookup) shows that Cos performs from 
x50 to X 100 faster, depending on the tested classes. 



The code above shows some typical usages: 



These testsuites can be browsed on sf.net in the module CosBase/tests. 
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Table 1. Performances summary in 10 calls/second. 



Multi-threading The same performance tests have been 
run with POSIX muhi-threads enabled. When the Thread- 
Local-Storage mechanism is available (Linux), no signif- 
icant impact on performance has been observed (<1%). 
When the architecture supports only PosiX Thread-Specific- 
Key (Mac OS X), the performance is lowered by a factor 
X 1.6 and becomes clearly the bottleneck of the dispatcher 

Object creation Like other languages with semantic by 
reference, Cos loads heavily the C memory allocator (e.g. 
malice) which is not very fast. If the allocator is identified 
as the bottleneck, it can be replaced with optimized pools 
by overriding galloc or by faster external allocators (e.g. 
Google tcmalloc). Cos also takes care of automatic objects 
which can be used to speed up the creation of local objects. 

Other aspects Other features of Cos do not involve such 
heavy machinery as in message dispatch or object creation. 
Thereby, they all run at full speed of C. Contracts run at the 
speed of the user tests since the execution path is known at 
compile time and flattened by the compiler optimizer Empty 
try-blocks run at the speed of set jmp which is a well known 
bottleneck. Finally next .method runs at 70% of the speed 
of an indirect function call (i.e. late binding) because it also 
has to pack the closed arguments into the generic's _arg 
structure. 

8. Component-Oriented Design Patterns 

This overview of Cos shows that the principles stated in the 
introduction are already well fulfilled. So far: 

• The simplicity can be assumed from the fact that the en- 
tire language can be described within few pages, includ- 
ing the grammar, some implementation details and few 
examples and comparisons with other languages. 

• The extensibility comes from the nature of the object 
model which allows extending (methods bound to gener- 
ics), wrapping (around methods) or renaming (method 
aliases) behaviors with a simple user-friendly syntax. Be- 




addTo4 

Figure 12. Performances summary in 10^ calls/second. 

sides, encapsulation, polymorphism, low coupling (mes- 
sages) and contracts are also assets for this principle. 

• The reusability comes from the key concepts of COS 
which enhance generic design: polymorphism, collabo- 
ration (multi-methods) and composition (delegation). 

• The efficiency measurement shows that key concepts per- 
form well compared to other mainstream languages. 

• The portability comes from its nature: a C89 library. 

It is widely acknowledged that dynamic programming 
languages simplify significantly the implementation of clas- 
sical design patterns 1281 when they don't supersede them 
by more powerful dynamic patterns fTl lSSllMl . This section 
focuses on how to use Cos features to simphfy design pat- 
terns or to turn them into reusable components, where the 
definition of componentization is borrowed from |fT6l[T7ll : 



Component Orientation = Encapsulation + Polymorphism 
+ Late Binding + Multi-Dispatch + Delegation. 



8.1 Simple Patterns 

Creational Patterns It is a well known fact that these pat- 
terns vanish in languages supporting generic types and intro- 
spection. We have already seen gnew (p.|5]l, here is more: 

OBJ gnewWithStr(QBJ els, STR str) { 
return ginitWithStr (galloc (els) , str); 

} 

DBJ gclone(OBJ ob j ) { 

return ginitWith(galloc (gclass (obj ) ) , obj); 

} 

The Builder pattern is a nice application of property meta- 
classes to turn it into the so called Class Cluster pattern: 

def method (OBJ , galloc, pmString) 

retmethod(_l) ; // lazy, delegate the task to initializers 
endmethod 
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def method (OBJ, ginitWithStr , pmString, (STR)str) 
□BJ lit_str = galloc(StringLiteral) ; 
retmethodC ginitWithStr (lit_str, str) ); 

endmethod 

This example shows how to delegate the object build to the 
initializer which in turn allocates the appropriate object ac- 
cording to its arguments, an impossible task for the allocator. 
The allocation of the stringLiteral uses the standard allo- 
cator inherited from Object, even if it derives from the class 
String (thanks to property metaclass). Now, the code: 

OBJ str = gnewWithStrCString, "literal string"); 

will silently return an instance of StringLiteral. This is 
the cornerstone of Class Clusters where the front class (e.g. 
String) delegates to private subclasses (e.g. StringLiteral) 
the responsibility to build the object. It is worth to note that 
each pmString speciaUzation needed to handle new subclass 
is provided by the subclass itself (thanks to the open class 
model), which makes the Builder pattern truly extensible. 
Most complex or multi-purpose classes of COS are designed 
as class clusters (e.g. Array, String, Functor, Stream). 

Garbage Collector This exercise will show how to sim- 
plify memory management in COS with only few hues of 
code. We start by wrapping the default object allocator such 
that it always auto-releases the allocated objects: 

def method (OBJ , (galloc) , mObject) // around method 
next_method(self ) ; //allocate 
gautoRelease(RETVAL) ; // auto— release 

endmethod 

Then we neutralize (auto-)delete and reinforce retain: 

def method (void, (gdelete) , Object) 
endmethod 

def method (OBJ , (gautoDelete) , Object) 
BOOL is_auto = self->rc == COS_RC_AUTO; 
retmethod( is_auto ? gclone(_l) : _1 ) ; 

endmethod 

def method (void, (gretain) , Object) 

next_method(self ) ; 

if (self->rc == COS_RC_AUTO) 
RETVAL = gretain(RETVAL) ; // once more for auto 
endmethod 

Now, the following code: 

OBJ pool = gnew(AutoRelease) ; 
for(int i = 0; i < 1000; i++) 

OBJ obj = gnewWithStr (String, "string"); 
gdelete (pool) ; //pool specialization, collect the strings 

does not create any memory leak, there is no longer the need 
to delete or auto-delete your objects. For the first runs, you 
can rely on the default auto-release pool managed by COS. 
Then a profiler of used memory will show the appropriate 
locations where intermediate auto-release pools should be 
added to trigger the collects and limit the memory usage. 



Key -Value-Coding We have already seen that properties 
allow accessing to object attributes, but to implement KVC, 
we need to translate strings (key) into properties (noun): 

def method (OBJ, ggetAt , Object, String) 

OBJ prp = cos_property_getWithStr(self 2->str) ; 
if (!prp) THROW (gnewWith(ExBadProperty, _2) ) ; 
retmethod( ggetAt(_l, prp) ); 

endmethod 

def method (void, gputAt , Object, String, Object) 
OBJ prp = cos_property_getWithStr (self 2->str) ; 
if (!prp) THR0W(gnewWith(ExBadProperty,_2)) ; 
gputAt (_1, prp, _3) ; 

endmethod 

where cos_property_getWithStr is an optimized version of 
cos_class_getWithStr for properties from the API of COS, 
which also provides cos_class_-[read,write}Properties 
to retrieve all the properties of a class (and its superclasses). 

Key-Value-Observing Adding access notifications of prop- 
erties is the next step after KVC, using around methods: 

def method (OBJ, ggetAt, (Person), mP_name) 
useclass (After , Before); 

OBJ context = aMthCall(_mth,_l ,_2 ,_arg ,_ret) ; 
gnotify (center , context. Before); 
next_method(self 1 , self 2) ; // get property 
gnotify (center , context. After); 
endmethod 

where _mth is the object representing the method itself. 

This example assumes that observers and objects observed 
have already been registered to some notification center as 
conomonly done in the Key- Value-Observing pattern. 

8.2 Proxies and Decorators 

Proxy Almost all proxies in COS derive from the class 
Proxy which handles some aspects of this kind of class: 

def class (Proxy) ; 

OBJ obj ; //delegate 
endclass 

#define guml gunrecognizedMessagel //shortcut 
#def ine gum2 gunrecognizedMessage2 //shortcut 

def method (void, gum2, Proxy, Object) 

f orward_message (self l->obj , _2) ; 

check_ret(_sel , _ret, selfl); 
endmethod 

def method (void, gum2, Object, Proxy) 

f orward_message (_1 , self2->obj); 

check_ret(_sel , _ret, self 2) ; 
endmethod 

// ... other rank specializations 

where the small function check_ret takes care to return the 
proxy when the forwarded message returns the delegate obj. 
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Tracer For the purpose of debugging, COS provides the 
simple proxy Tracer to trace the Hfe of an object: 

def class (Tracer , Proxy) // usage: gnewWith(Tracer, obj); 
endclass 

def method (void, guin2, Tracer, Object) 
trace_msg2 (_sel , self l->Proxy . obj , _2) ; 
next_method(self 1 , self 2) ; //forward message 

endmethod 

def method (void, guin2. Object, Tracer) 
trace_msg2 (_sel , _1, self 2->Proxy. obj) ; 
next_method(self 1 , self 2) ; //forward message 

endmethod 

// ... other rank specializations 

where trace_msg2 prints useful information on the console. 

Locker The locker is a proxy which avoids synchroniza- 
tion deadlock on shared objects that can be encountered in 
programming languages supporting only single-dispatch JQ: 

def class (Locker , Proxy) // usage: gnewWith( Locker, obj); 

pthread_mutex_t mutex; 
endclass 

def method (void , guml , Locker) // like smart pointers 
lock(self ) ; // lock the mutex 
next .method (self ) ; //forward the message 
unlock(self ) ; // unlock the mutex 

endmethod 

def method (void, gum2. Locker, Locker) 
sorted_lock2 (self 1 , self 2) ; // lock in order 
next_method(self 1 , self 2) ; // forward the message 
sorted_unlock2(self 1 , self 2) ; // unlock in order 

endmethod 

// ... other rank specializations (total of 63— 6 combinations) 

For the sake of efficiency, higher ranks use sorting networks. 

Multiple Inheritance The first version of Cos was na- 
tively implementing multiple inheritance using the C3 algo- 
rithm Ii351 to compute the class precedence list on the way 
of Dylan, Python and Perl6. But it was quickly consid- 
ered as too complex for the end-user and incidental as far as 
fast generic delegation could be achieved. Indeed, multiple 
inheritance can be simulated by composition and delegation 
with an efficiency close to native supporj*^ 

def class (lOStream, OutStream) 

OBJ in_streaiii; 
endclass 

def method (void, guml, lOStream) 

f orward_message (self ->in_stream) ; 
endmethod 
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Now, messages of rank one not understood by the IDStreams 
{e.g. gget, gread) will be forwarded to their InStream. 

Distributed Objects Without going into the details, we can 
mention that Cos already implements all the key concepts 
required to develop a distributed object system on the model 
of Objective-C and Cocoa. A challenge for the future. 

8.3 Closures and Expressions 

Cos provides the family of geval« messages (equivalent 
to Common Lisp f uncall) and the class cluster Ftmctor 
to support the mechanism of closures and more generally 
lazy expressions and high order messages. The objects rep- 
resenting the context of the closure {i.e. the free variables) 
are passed to the Functor constructor which handles partial 
evaluation and build expressions. The next example shows 
another way to create a counter in Perl using a closure: 

1 sub counter { 

2 my($val) = shift; # seed 

3 $cnt = sub { # incr 

4 return $val++ ; 

>; 

6 return $cnt; # return the closure 

I } 

8 

9 $cnt = counter(O); 

10 for($i=0; $i<25000000; $i++) 

II &$cnt(); 

which can be translated into Cos as: 

1 OBJ counter (int seed) { 

2 OBJ fun = aPunctor (gincr , aCounter (seed) ) ; 

3 return gautoDelete (f un) ; 

4 > 

5 

6 int main(void) ■[ 

7 OBJ cnt = counter(O) ; 

8 for (int 1=0; K25000000; i++) 

9 geval (cnt) ; 

.0 } 

The line |2] creates the closure using the automatic construc- 
tor aFunctor which takes the generic function glncr and 
deduces its arity (here 1) from the remaining parameters, 
namely the seed boxed in the counter Line [3] the message 
gautoDelete extends the lifespan of both the functor and the 
counter to the dynamic scope. As one can see, Cos achieves 
the same task as PERL with about the same amount of code 
but runs more than x \h faster. The example below: 

fun = gaddTo (Var , y) // works only with messages 

f un = aFunct or ( gaddTo , Var , y ) // works with functions 

create a closure with arity 2 where Var specifies an argu- 
ment placeholder and y an argument object. The message 
gevall (fun , x) is then equivalent to gaddTo (x , y) . 

The following example shows a more advanced example 
involving lazy expressions and indexed placeholders: 
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//return f = {f{x + dx) ~ f{x))/dx 

□BJ ggradient (OB J f) i 

OBJ X = aVar(O); // placeholder #1 

OBJ dx = aVar(l); // placeholder #2 

OBJ f_x = gevalKf, x) ; // lazy expression 

OBJ f_xpdx = gevalKf, gadd(x, dx) ) ; //idem 

return gdiv(gsub(f _xpdx, f _x) , dx) ; //idem 

} 

// return f'{x)\dx 

OBJ gderivative(OBJ f, OBJ dx) -[ 

return geval2 (ggradient (f ) , Var, dx) ; 

> 

Now we can map this function to a bag of values (strict 
evaluation) or expressions (lazy evaluation) indifferently: 

OBJ fun = gderivative (f , dx) ; 
OBJ new_bag = gmap(fun, bag) ; 

High Order Messages The principle behind HOMs is to 
construct on-the-fly an expression from their arguments 
composition ||37J — a technique known for more than a 
decade in C++ meta-programming. Once the expression is 
completed, the last built object evaluates the expression and 
returns the result. While C++ meta-expressions rely strongly 
on static types (i.e. traits) and templates to build and simplify 
the expressions, HOMs rely on the delegation mechanism: 

• With fast generic delegation, no need to cache the mes- 
sage in the HOM objects as in the aforementioned paper. 

• With multi-methods, no need to provide multiple HOMs 
for similar tasks [i.e. gf ilter, gselect and gcollect). 

• With lazy expression, no need to construct complex meta- 
expressions or to reorder compositions. 

HOMs are an important tool for modem framework design 
since they play the role of weavers of cross-cutting concerns 
otherwise solved by foreign technologies based on subject- 
oriented [38 1 and aspect-oriented programming [39J. Like- 
wise, the availability of HOMs simplify drastically the im- 
plementation of interpreters reflecting the classes and meth- 
ods of the underlying language like in F- SCRIPT f43\. 

9. Conclusion 

Some frameworks, with the help of external preprocessors 
or compilers, propose extensions to the C programming lan- 
guage, but none of them provide a set of features as consis- 
tent, complete and efficient as Cos. Besides, even if the fea- 
tures of Cos are not new, I am not aware of a single program- 
ming language which provides the same set of features with 
the same simplicity, portability and efficiency. Finally, very 
few programming languages target all the principles stated 
in the introduction. In particular, modern type systems which 
try to improve code flexibility and reusability to ease the de- 
sign of generic components, tend to be lazy (static duck typ- 
ing), overcomplicated (C++ ADL) and counter productive for 
average or occasional developers. 



9.1 Related work 

Ooc This old framework uses the ooc preprocessor written 
in AWK BOl to provide a basic object-oriented layer. It relies 
on void pointers and requires much defensive programming 
to ensure correct use of objects. Besides, it gives full control 
over inheritance like in prototype-based languages. 

Dynace This framework includes the dpp preprocessor and 
a large library of classes BTl . Dynace features are equivalent 
to those of Objective-C except that it supports multiple 
inheritance. However, Dynace message dispatch is about x3 
slower than COS even with jumpTo assembly code enabled 
and accessing object attributes is a bit awkward and relies on 
fancy macros (e.g. accessIVs, GetIVs, ivPtr, ivType). 

Gnome Objects The Gnome/Gtk+ Object System provides 
basic object-oriented programming and requires to write un- 
safe and unchecked code. Despite that this system cumulates 
all the problems of Ooc and Dynace, it is nonetheless simple, 
portable and implements a prototype-based object model. 

9.2 Summary 

Cos seems to be unique by the set of features it provides to 
the C programming language without requiring a third party 
preprocessor or compiler nor any platform or compiler spe- 
cific feature. The library approach allowed to explore rapidly 
some object models and to select the most appropriate one 
fulfilling the best the aimed principles: simplicity, extensi- 
bility, reusability, efficiency and portability. Moreover, the 
list of features is complete and consistent: augmented syn- 
tax to support object-oriented programming, uniform object 
model with extended metaclass hierarchy, multi-methods, 
fast generic delegation, design by contract, properties and 
key-value coding, exceptions, ownership and closures. CoS 
features have been optimized from the design point of view, 
but for the sake of simplicity and portability, code tuning 
has never been performed and lets some room for future im- 
provement. The 8000 lines of source code of Cos can be 
downloaded from sourceforge.net under the LGPL license. 
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